Avoid import-time dependency on typing in common cases
#329
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Part of #326.
Overview
typingas a import-time dependency can be avoided for most of this library's use cases through a combination of the following:typing.functools.singledispatchtypingat import time, so that importing them is opt-in.importlib_resources.abc.Traversable__getattr__.This way, when importing just the base or functional API (
files(),as_file(),open_binary, etc.), which I imagine is a very common use case, users don't also importtypingimmediately as a side-effect. This will improve the import time ofimportlib_resourcesfor such common cases by at least 10%, possibly more, while still having the type annotations be valid and resolve to the correct symbols when introspected/evaluated.This PR's intended viewing is commit by commit, in order.
Notes
I'm guessing this one will be a bit more controversial than the other PRs due to refactoring away usage of
functools.singledispatch, but if we want to usetypingwithout incurring its import cost on multiple Python versions, I think it's easiest to just avoidsingledispatchaltogether inimportlib_resources._common.singledispatchusage is also a potential blocker for possible future improvements, e.g. lazily importingpathlib.Path.That being said, I'll try to see if there's a way to use
singledispatchfor the moment without it unconditionally importingtyping. Doing so would rely on implementation details and thus be fragile at best, so I'm not a fan of it.